Teamprojekt Softwareentwicklung

Vorlesung in 2 Wochen

• Projektkalender

• Meilenstein: “MVP” Anfang Januar

• Abgabe: Projektdokumentation Ende Februar

• Abgabe: Projektpräsentation individuelle Blocktermine Anfang März

Iteration

• 2-wöchiger Planungsprozess

• Treffen mit AG

• Anforderungen verwalten

• Software entwickeln

• Qualitätssicherung

• Laufende Software liefern

Treffen mit AG

• Abnahme von implementierten User Storys

  • Oft live Demo + abnicken

• Definition von weiteren Anforderungen

• Priorisierung von Anforderungen für die nächste Iteration

Treffen mit Gruppe

• Reflexion/Anpassung der Anforderungen

  • Zu groß? Schlechte Schätzung? Zu unklar?

  • Anpassungen mit AG absprechen

• Aufgabenverteilung

• Planung des AG treffen

• Reflexion was gut funktioniert, was besser funktionieren könnte

Protokolle

• Vor dem Treffen festlegen, wer Protokolliert.

• Notiert wichtiges:

  • Neue Anforderungen

  • Was ist dem AG wichtig

  • Absprachen/Entscheidungen

  • Punkte die auf später verschoben wurden

Anforderungen

• „Vertrag zwischen AG und Gruppe“

• Werden vom Team erstellt, vom AG abgenommen

  • Das ganze Team sammelt Anforderungen

  • Keine Trennung zwischen

    • „Entwickler:innen“ und

    • „Menschen die Anforderungen sammeln“.

• Basieren auf Input vom AG, von eventuellen Nutzern, oder eigeninitiativ.

• Kleinteilig genug, damit mehrere pro Iteration bearbeitet werden können

• Mehrwert für die Projektziele

• Achtet auch auf nicht-funktionale Anforderungen!

  • Sicherheitsstandards

  • Laufzeitumgebung

Anforderungsmanagement

• Anforderungen müssen dokumentiert sein

  • User Stories

  • Issues

  • Tasks

  • Cards

  • Prototypen/Mockups

• Nutzt Formate die mit euren Werkzeugen funktionieren!

Struktur von Anforderungen

• Unbearbeitet:

  • Deskriptor

  • prüfbare Akzeptanzkriterien

  • Aufwandsschätzung

• Erledigt:

  • in Iteration X

  • Aufwand in Stunden pro Teammitglied

Beispiel 2

Anforderung 101: Nutzersymbole

• Akzeptanzkriterium: Die Spieler werden auf der UI mit farblich unterscheidbaren Symbolen dargestellt.

• Geschätzer Aufwand: 1 Punkt.

• Tatsächlicher Zeitaufwand: (noch offen)

Story Points

• Abstrakte Aufwandsschätzung

• Punkte:

  • 0, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, $\infty$, ☕, ?

• Relativ zu anderen Anforderungen

Pointing Poker

• Jeder schätzt für sich

• Dann wird Konsensus gebildet

  • Diskutiert abweichende Meinungen

• https://www.pointingpoker.com/

• https://pokerplanning.org/

Velocity

• Im Nachhinein

• Wie viele Stunden pro Story Point?

• (Wie viele Story Points pro Iteration?)

Iterationszyklus

• Neue Version der Software

  • Erfüllte Akzeptanzkriterien?

  • Velocity der erfüllten Anforderungen?

  • Gesamtstorypoints in dieser Iteration?

• Neue Anforderungen?

• Änderung an existierenden Anforderungen?

• Prioritäten für existierende Anforderungen?

• Welche Anforderungen werden in dieser Iteration bearbeitet?

  • Arbeitet wichtige einfache Anforderungen zuerst ab

Qualitätssicherung

(siehe auch W04 Qualitätssicherung)

Auftraggeber*in: Ich möchte eine Fitnessanwendung entwickeln lassen mit der Benutzer*innen ihren Fortschritt speichern und planen können (als Anzahl absolvierter Trainings, gestemmtem Gewicht, gelaufener Zeit etc.).

Noch keine QS Ziele

Ziele identifizieren

Es soll verschiedene Ansichten auf die Daten geben, da wir Nutzer*innen haben, die unterschiedlich viel Details sehen wollen.

Vermutlich ist Datensicherheit wichtig, muss aber konkretisiert werden.

Wir haben Anfänger*innen und Expert*innen in der Zielgruppe. Sie sollen sich alle damit zurechtfinden können.

Benutzbarkeit

Nach dem BP will ich vielleicht ein weiteres Praktikum ausschreiben, in dem die Anwendung noch weiterentwickelt wird.

Wartbarkeit

QS Maßnahmen

Wartbarkeit:

Wir beschränken uns darauf, die Lesbarkeit des Quellcodes und zugehöriger Kommentare sicherzustellen. Hierbei folgen wir dem […] Style Guide, welcher […]. Außerdem stellen wir die Erweiterbarkeit der Anwendung bzgl. Datenansichten sicher, da hier schon jetzt Erweiterungen abzusehen sind. Um die Lesbarkeit zu gewährleisten, führen wir statische Code Analysen durch. Hierzu setzen wird folgendes Tool ein […].

Qualitätssicherung

• Ziele

  • mit dem AG koordiniert

  • klar beschrieben

  • überprüfbar

  • erreichbar

• Maßnahmen

  • Was wird getan?

  • Wer führt die Maßnahme durch?

  • Wann wird die Maßnahme ausgeführt?

  • Welche Konsequenzen werden nach der Durchführung ergriffen?

QS Planung

• Überlegung: Welche Ziele sind sinnvoll für das Projekt? Abstimmung mit AG

• Konkretisierung und Abgrenzung der Ziele

• Überlegung: Wie wird der QS-Prozess am besten in den Entwicklungsprozess integriert?

• Recherche: Welche Tools können die QS unterstützen?

• Festlegen: Wie werden die Belege der QS Durchführung am besten gesammelt?

QS Kategorien

• Datensicherheit

• Zuverlässigkeit

• Portabilität

• Wartbarkeit

• Effizienz

• Benutzbarkeit

• Funktionalität

• Kompatibilität

Vorgegebene QS Ziele & Maßnahmen

• Wartbarkeit, Zuverlässigkeit

• Code Reviews, Tests, Pair Programming

• Weitere nach Wunsch der AGs

  • Macht nicht zu viel!

Code Reviews

• Reviewer hat code nicht geschrieben.

• Jeder code wird gereviewt.

  • Wann? (z.B. vor Akzeptanz)

  • Checkliste.

Pair Programming

• Eine Person macht Eingaben

  • Beide Denken nach

• Jedes Teammitglied paar mindestens ein mal im Projekt

• Dient der Wissensweitergabe

Tests

• Manuell

  • Checklisten!

  • Prüfbarkeit!

• Automatisch

  • Unit

  • Integration

  • Continuos Integration

• Wie ist der Prozess bei Testfehlern?